What?

Currently the RichText value is passed to the store as HTML, but it can be useful to have access to the rich text value.
Solution: pass an instance of RichTextValue, which inherits from String, but has additional properties.

Currently the RichText value is passed to the store as HTML. This PR creates a new rich-text type and rich-text matcher so that rich text data can be stored directly in block attributes and the block editor store.

Why?

Storing rich text data in the block attributes and the block editor store has many advantages.

1. We no longer need to constantly parse and serialise the HTML. This currently happens both on load and on typing. When the blocks packages parses the blocks, it actually has access to the DOM tree. What we currently do is serialise that content back to HTML (with innerHTML) and then the rich-text has to parse it again. Similarly on typing, the internal value needs to be constantly serialised before it can send the change to the store.
2. Related to that, when something external wants to operate on rich text, it only has access to the serialised HTML, so it must parse it, do something with it, then serialise it again before setting attributes. This is not just an issue outside of core GB (like Tumblr), but also inside core. We have this problem in our splitting and merging logic (all outside of rich text, in the writing flow component), and also in footnotes. Similarly, it's tough to do Multiple blocks: Keep all text formatting icons #27221 without it.
3. Additionally, it’s been blocking further performance improvements with rich text buttons for example. Currently this UI needs to be portalled from inside rich text, because outside of it there’s no access to the value.
4. Having unique objects has a value too. With strings, if you have the same content, the strings are equal, so you can’t easily find and update a rich text value inside a blocks tree. With unique values, you can just loop through all attributes until you find the unique match.
5. Having an object means that you can store additional meta information. For example, we could store the attribute key that the data saves to (currently called the identifier). This means that we can remove the identifier prop from rich text and block authors don’t need to think about it. It’s can be a source of bugs because the identifier is easily forgotten (even in core blocks), and you could give a wrong identifier/attribute keys. What’s worse is that it's again only accessible to the rich text instance. In order to make further improvements to writing flow, we’ll need to store these identifiers in the DOM so that they’re known outside of rich text (Writing flow: absorb partial multi selection dispatching #47525).
6. Similarly, we'd no longer have insert special characters like START_OF_SELECTED_AREA to keep track of the selection when splitting and merging, because we can now simply set a property to the object.
7. Annotation/comments that are stored within the rich text value (but removed on serialisation) will now also be stored in the block attributes, which means they'll be preserved when splitting and merging rich text instances!
8. Currently, the start/end selection index in the store actually refers to the rich text selection index, while the content is stored as HTML, so these indices are useless without converting to a rich text value.
9. Further, the idea is to add rich text manipulation tools directly to the class as methods (similar to string methods), making it even easier to work with.

How?

With a new rich-text type and source added to the block attribute schema.

Testing Instructions

Screenshots or screencast